WIDGET FRAMEWORK, REAL-TIME SERVICE ORCHESTRATION, AND REAL-TIME RESOURCE AGGREGATION
A method to optimize calls to a service by components of an application running on an application server is provided. The method includes receiving a first call and a second call, the first call made to a service by a first one of a plurality of components included in the application, and the second call made to the service by a second one of the plurality of components; selecting one of a plurality of optimizations, the plurality of optimizations including orchestrating the first call and the second call into a third call to the service; and, in response to the selecting of the orchestrating of the first call and the second call into the third call as the one of the plurality of optimizations, orchestrating the first call and the second call into the third call.
This application is a continuation of U.S. application Ser. No. 12/754,564, filed Apr. 5, 2010, which claims the priority benefit of U.S. Provisional Application No. 61/302,082, filed Feb. 5, 2010, all of which are incorporated herein by reference.TECHNICAL FIELD
The present application relates generally to the technical field of optimizing server performance, and, in one specific example, to optimizing an efficiency of calls to services by components of an application running on an application server.BACKGROUND
To be competitive in a global market, a network-based marketplace that serves a large, world-wide community of users may find it beneficial to meet objectives of (1) rapidly developing, modifying, testing, or deploying a large number of server-side applications such that rapidly-changing needs of the users are met, (2) optimizing the server-side applications such that their deployment does not violate resource and performance constraints. In one approach, the network-based marketplace may achieve its objective by employing a large-sized group of developers to code each server-side application by hand; however, such an approach may have various drawbacks, including producing applications that have a less consistent look-and-feel, take a longer time to develop, or are less efficient in terms of, for example, reuse of code, than applications produced using other approaches. In another approach, the network-based marketplace may achieve its objectives by employing a small-sized group of developers to code applications that conform rigidly to a template; however, such an approach would also have various drawbacks, including producing applications that are more difficult to customize, consume more resources, or have slower performance than applications produced using other approaches.
Some embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings in which:
In the following description, for purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments of the inventive subject matter. It will be evident, however, to those skilled in the art that embodiments may be practiced without these specific details. Further, well-known instruction instances, protocols, structures, and techniques have not been shown in detail. As used herein, the term “or” may be construed in an inclusive or exclusive sense.
The term “BizMo” includes a business module that may include user interface (UI) presentation, data/service access, including input, or configuration. The term “Action Input” includes input parameters for a Business Module to make an action. The term “BizOp” or “BizOperation” includes business operations a business module may delegate to an outside entity (e.g., a service call). A BizOp may be plugged in as a strategy into a business module. The term “BizMo View” includes the UI of a business module. The term “View Builder” includes a UI builder that can be plugged in as a strategy into a business module. The term “BizMoManager” includes a controller that drives a life cycle of a business module. The term “BizOpEngine” includes an engine that optimizes and executes business operations. The terms “BizMo,” “widget,” and “business module” may be used interchangeably. The term “user” includes a person or a machine. A component of an application may include a widget.
In an example embodiment, a system to optimize calls to a service by components of an application running on an application server is provided. The system includes a call optimizer in the application. The call optimizer includes an intercepting module to intercept a first call and a second call, the first call made to a service by a first one of the components and the second call made to the service by a second one of the components; and an orchestrating module to orchestrate the first call and the second call into a third call.
In another example embodiment, a system to optimize calls to the service by components of the application running on the application server is provided. The system includes a call optimizer associated with the application. The call optimizer includes the intercepting module to intercept the first call and the second call; an optimization-selecting module to select one of multiple optimizations, the multiple optimizations including orchestrating the first call and the second call into the third call; and the orchestrating module to, in response to the selecting of the orchestrating of the first call and the second call into the third call as the one of the multiple optimizations, orchestrate the first call and the second call into the third call.
In another example embodiment, a method to optimize the calls to the service by the components of the application running on the application server is provided. The method includes receiving the first call and the second call, the first call made to the service by a first one of the components, and the second call made to the service by the second one of the components; selecting one of multiple optimizations, the multiple optimizations including orchestrating the first call and the second call into the third call to the service; and, in response to the selecting of the orchestrating of the first call and the second call into the third call as the one of the multiple optimizations, orchestrating the first call and the second call into the third call.
In another example embodiment, a machine-readable storage medium comprising instructions that, when executed by one or more processors of a machine, causes the machine to perform a method to optimize the calls to the service by the components of the application running on the application server is provided. The method includes receiving the first call and the second call, selecting one of multiple optimizations, the multiple optimizations including orchestrating the first call and the second call into the third call to the service; and, in response to the selecting of the orchestrating of the first call and the second call into the third call as the one of the multiple optimizations, orchestrating the first call and the second call into the third call.
The relationship between the widget 1 112 and the data source 2 136 may be that the widget 1 112 calls a service of the data source 1 132. Similarly, the relationship between the widget 2 114 and the data source 2 136 may be that the widget 2 114 also calls the service of the data source 2 136. The relationship between the widget 1 112 and the resource 1 134 may be that another component (not shown) of the application 102 upon which the widget 1 112 may be included uses the resource 1 134. For example, the widget 1 112 may be included in a document written in a markup language (e.g., HTML, XHTML, XML, SVG, or XUL), and the document may, in turn, be included in the application 102.
Each of the data sources may be a web service. Furthermore, each of the data sources or resources may be located locally (e.g., on a same server, a same system, or a same network) or remotely (e.g., on a different server, a different system, or a different network) with respect to the application 102.
Furthermore, the incorporation of the resource aggregator 118 has resulted in an addition of a resource 3 142, an establishment of a relationship between the widget 1 112 and the resource 3 142, and an establishment of a relationship between the widget 2 114 and the resource 3 142. Resource 3 142 may include an aggregation of elements of resource 1 134 and resource 2 138 that application 104 uses. Resource 3 142 may not include elements of resource 1 134 or resource 2 138 that are redundant with each other. Thus, the incorporation of the call optimizer 116 into the application 104 may cause a number of service calls upon which application 104 relies to be reduced, and the incorporation of the resource aggregator 118 into the application 104 may cause a number of resources upon which the application 104 relies to be reduced. This optimization of service calls and aggregation of resources may improve the efficiency or performance of the application 104.
The applying of the orchestrating of the calls may include integrating a plurality of request parameters of the first call into a plurality of request parameters of a third call, integrating a plurality of request parameters of the second call into the plurality of request parameters of the third call, making the third call, receiving a result of the third call, identifying a first part of the result as corresponding to the first call, identifying a second part of the result as corresponding to the second call, providing the first part of the result to the first one of the plurality of components as a response to the first call, or providing the second part of the result to the second one of the plurality of components as a response to the second call. Other ones of the multiple techniques of optimizing the calls are described below with reference to
The batching module 242 may, in response to a selection of the making of the batch call as the one technique of optimizing the calls, make a batch call instead of the first call or the second call. The batch call may be offered as a service of a data source to which the first call and the second call were directed. Thus, the selection of the making of the batch call may be based on the availability of the batching service at the data source. Furthermore, the selection of the making of the batch call may be based on a determination that a first part of a result of the batch call is usable as a response to the first call and a second part of the result of the batch call is usable as a response to the second call.
The caching module 244 may, in response to a selection of the providing the response to the first call or the second call from the cache as the one technique of optimizing the calls, provide a response to the first call or the second call using data contained in a cache in a memory instead of providing a response received from a making of the first call or the second call, respectively. The data contained in the cache in the memory may be a response received from a making of a third call to the service. Furthermore, the selection of the providing the response to the first call or the second call from the cache as the one technique may be based on a determination that the third call is substantially identical to the first call or the second call, or that the making of the first call or the second call is otherwise redundant with the making of the third call.
The executing module 246 may generally handle the execution of the calls. The executing module 246 may, in response to a selection of the executing the first call and the second call in parallel as the one technique, execute the first call and the second call in parallel. The selection of the executing of the first call and the second call in parallel may be based on a determination that the first call is not dependent on the second call or the second call is not dependent on the first call. The executing module 246 may handle a forwarding of a response to a call to an appropriate component (e.g., widget 1 112 of
For simplicity, the above discussion refers to applying a single optimization technique with respect to a first call and a second call. However, it should be understood that call optimizer 116 may intercept one or more calls made by one or more application components, select one or more call optimizations with respect to the one or more calls, and apply the one or more call optimizations to the one or more calls. For example, call optimizer 116 may process any number of calls or apply any number of optimization techniques to the any number of calls. Additionally, the call optimizer 116 may perform operations in parallel or in serial. Moreover, the call optimizer 116 may perform operations automatically at run time. Nevertheless, an effect of the performance of the operations may be to make a component (e.g., a web page) of an application (e.g., application 102) perform as if it was optimized by manual or hand-coding by an application developer at design time. Furthermore, the call optimizer 116 may apply one or more optimizations to one or more calls from one of the one or more application components. In other words, the call optimizer 116 is not limited to applying the one or more optimizations to one or more calls from more than one component.
The aggregating module 224 may, in response to the identifying that at least the portion of the first resource is redundant with at least the portion of the second resource, aggregate the first resource and the second resource into a third resource. The third resource may include portions of the first resource and portions of the second resource that the application uses.
The updating module 226 may update the application to use the third resource. The updating of the application may remove a dependency of the application on the redundant portion of the first resource or the redundant portion of the second resource. For example, the updating module 226 may update the application to include in the third resource a portion of the first resource instead of the redundant portion of the second resource. Thus, the updating module 226 may reduce an overall size of resources upon which the application depends. Furthermore, the updating module 226 may externalize the third resource such that a client may cache the third resource instead of the first resource or the second resource. For example, the client may download and cache the third resource upon accessing the application for a first time. Then, upon accessing the application for a second time, the client need not download the third resource again. The resource aggregator 118 may perform resource aggregation automatically at run time. Nevertheless, an effect of the resource aggregation may be to make a component (e.g., a web page) of an application (e.g., application 102) appear as if it was optimized by manual or hand-coding by an application developer at design time.
The logic-implementing module 264 may implement the logic of the widget 1 112. The implementing of the logic may include accessing one or more data sources (e.g., data source 1 132 or data source 2 136, both of
The connecting module 266 may connect the presenting module 262 to the logic-implementing module 264 such that the presenting module 262 can integrate into the one or more UIs a presentation of data received from the logic-implementing module 264, including data that the logic-implementing module 264 receives through the accessing of the one or more data sources.
The configuring module 268 may expose configurable attributes of the widget 1 112 through a configuration API. The configuration API may give programmatic access to configuration data associated with the widget 1 112 (e.g., a data schema). The configuration API may allow the widget 1 112 to be configured through a simple user interface (e.g., a user interface of a tool that accesses the widget 1 112 through the configuration API) instead of requiring the widget 1 112 to be configured manually (e.g., through hand-coding of an XSD schema associated with an XML file). The configuration API may include functions to define or apply a theme (e.g., a Christmas or Halloween theme) to the widget 1 112. The applying of the theme may include a modifying of multiple ones of the configurable attributes of the widget 1 112 in a single operation. If the widget 1 112 is a search widget, the configuration API may expose a default search string as a configurable attribute of the widget 1 112. The configuration API may then be invoked to set the default search string (e.g., to “waterproof boots,” “MP3 players,” or another string). The configuration API may include functions to define or apply a localization of the widget 1 112. The applying of the localization may result in a changing of the text or images associated with the widget 1 112 based on a locality (language, region, and so on) of a user accessing the widget 1 112. For example, applying a German (e.g., de-DE) localization to the widget 1 112 may cause text associated with the widget 1 112 to be in the German language, whereas applying an English as used in the United States (e.g., en-US) localization to the widget 1 112 may cause the text associated with the widget 1 112 to be in the English language.
The metadata framework may support a defining of types using a domain-specific language (DSL). The DSL may use a prototype-based approach in which model (or data) definitions (e.g., an IDataDef interface) are correlated with model (or data) instances (e.g., an IManagedData interface). The IDataDef interface may be at the top of the DSL definition hierarchy. The IDataDef interface may manage a lifecycle of the definition, including a structural definition or a data layering. The IDataDef interface may hold a type hierarchy or definitions of constraints, actions, or transformations. The DSL definition hierarchy may include a simple-value-unit-definition interface (e.g., an ISimpleValueUnitDef interface) that manages a conversion of an object from one type to another type (e.g., a conversion of Java objects to or from strings). The DSL definition hierarchy may include a complex-data-definition interface (e.g., an IComplexDataDef interface) that holds definitions of attributes or associations. The complex-data-definition interface may also include implementations to manage multiple semantics corresponding to the associations. For example, the complex-data-definition interface may include bean-like structures (e.g., StructDataDef objects) that become classes through a code-generation process or interface-like choices or alternatives (e.g., ChoiceDataDef objects) that become interfaces or enumerations through the code generation process.
The metamodel framework may support a prototype-based paradigm rather than a class-based inheritance paradigm. For example, a first web page with a header, content, or footer may be a prototype for a second web page with a more detailed header. The second web page may, in turn, be a prototype for a third web page with the more detailed header and a left-side navigation pane. A sub-classed prototype may add constraints, such as prototype invariants (e.g., validation rules) or value restrictions (e.g., enumerated strings or minimum or maximum values). The sub-classed prototype may not remove anything (but may change multiplicity to 0). The sub-classed prototype may add or mix in new attributes or structural elements (e.g., a mix-in may add namespace support to avoid name collisions). The sub-classed prototype may weave in behavior in the form of actions (e.g., arbitrary code to read or write a model) or transformations (e.g., code to convert or polymorph data from one type to another).
The metamodel framework may support a model (or metadata) definition lifecycle. That is, the metamodel may (e.g., using the prototype-based approach) support model definitions that combine a structure definition and a data setting operation. The data setting may include setting values associated with an instance of an object of a type based on the structure definition. Such an object may be referred to as managed data.
The metamodel framework may include a model definition factory. The model definition factory may be used to get an instance of a definition or prototype. The model definition factory may support a single factory or reference model for new types and adapted (e.g., legacy) types. The model definition factory may be used by code generators (e.g., to generate 454 the type definitions or to generate 456 the API). The model definition factory may be used by tools (e.g., editors or metamodel-driven tools). The model definition factory may manage the metadata definition lifecycle. The model definition factory may support recursive types or layering of data. The model definition may support a registering of framework- or container-provided or application-specific metadata definition injectors. The framework-provided, container-provided, or application-specific metadata definition injectors may be implemented via a callback mechanism.
Thus, the example architecture 300 of the metamodel framework may provide a Java-based model definition that enables type-safe plain-old Java object (POJO) model generation with key-value-coding (KVC) support, a generation of an XML marshaller or unmarshaller, a providing of run-time Java APIs for querying definitions for tooling, XSD or XMI (UML) generation for documentation or tooling purposes. The benefits of the metamodel framework may include a consistent interface for both definition and data consumption, reuse of definitions across different parties or legacy systems, tooling support (discoverability or definitions or tooling helpers), prototype-based definitions that allow mix-type definitions or value settings throughout the inheritance process, separation of concerns via mixins of multiple definitions or AOP definition injectors, separation of concerns via behavior weaving (e.g., transformers or type-safe accessors for references), or definition versioning to support a specification of a “compatibility key” (to be stored in each resource) or provide version converters to migrate incompatible versions.
The configuring module 268 of
The repository layer 942 may include a repository-level API (e.g., IresourceRepository 944) to manage storage of the resources in memory (e.g., volatile memory). The repository-level API may be associated with a resource repository implementation 946 that supports registration of adapters to legacy resources, a serializer, or a converter. In this way, the repository-level API may support using a same referencing model across multiple owners or legacy systems. The repository-level API may support a definition of a repository structure (e.g., logical keys of resource). The repository-level API may support conversions or serializations of the resources between various formats (e.g., between a volatile memory format and a non-volatile memory format, between a legacy system format and a current system format, or between other formats). The repository-level API may be a Java-based type-safe wrapper of underlying resource repositories. The repository-level API may include a resolver to support mappings between logical and physical keys. The resolver may be resource-pattern aware. For example, the resolver may support permutations (e.g., sites or locales), versioning (e.g., release “train” numbers), lifecycle states (e.g., a review state or a production state) or compatibility management. The repository-level API may support infoset-based persistence, leveraging fast or compact binary XML serializations; support for granular target, overrides, binding, or layering attributes; or a pluggable serializer or deserializer. The pluggable serializer or deserializer may not be coupled to the metamodel framework. The repository-level API may support a tracer to trace resource usage. The repository-level API may also support management of instances of data types (e.g., managed data). The respository-level API 944 may apply resources to type-safe KVC objects as well as generic objects. The repository-level may also expose definitions of objects (e.g., type declarations) to be edited (e.g., via a tool).
The repository layer 942 may be associated with a storage persistence interface 962. The storage persistence interface 962 may include a persistence-manager API (e.g., IResourcePersistenceManager 964) to provide a common API to the underlying persistent (e.g., non-volatile) storage implementations 982, which may include a storage-as-a-service (StaaS)-based implementation 984, a proxy-service implementation 986, a file-system-based implementation 988, or a service-oriented-architecture (SOA) client-based implementation 990. The Staas-based implementation 984 may support hot deployment and fast roll-out or roll-back (e.g., data center replication) or run-time source of truth (e.g., UGC) and override support). The proxy server may include a fetcher or a local disk cache (e.g., for high performance). The SOA client-based implementation 990 may, in turn, be based on one or more SOA services (not shown) or an additional StaaS-based implementation (not shown). The management of the storage and retrieval of the resources may be performed at run time.
Thus, an example embodiment of the architecture 900 of the resource framework may include a resource repository that provides uniform API to access resources but allows for an addition of type-specific APIs, a resource persistence service that provides pluggable persistence mechanisms, or a prototype resource repository as an out-of-the-box solution from design time to run time. In this way, the example embodiment of the architecture 900 may extend best practices and features to most resource types, be easy or cheap to maintain or troubleshoot, or provide an easy go-to solution for most configuration externalization needs.
The widget manager 1040 may manage widget 1 1012 and widget 2 1024, including their lifecycles or run-time operation. The widget manager 1040 may include a reference 1042 to widget 1 1012 or a reference 1044 to widget 2 1024. Furthermore, the widget manager 1040 may include references to steps within each widget. For example, the widget manager 1040 may include a reference 1046 to step A1 1022 or a reference 1052 to step B1 1022. The widget manager 1040 may intercept a call from a widget to a service and forward the call to a widget engine 1060.
The widget engine 1060 may handle the processing of one or more calls by a widget. For example, the widget engine 1060 may receive a reference 1062 to OP1 1008 or a reference 1064 to OP5 1026 from the widget manager 1040 (e.g., in response to an intercepting by the widget manager 1040 of a call by widget 1 1012 to OP1 1008 or a call by widget 2 1024 to OP5 1026. The widget engine 1060 may include an optimizer 1066, an executor 1068, or a cache 1070. The optimizer 1066 may optimize the calls as discussed above with reference to
The developer tool 1122 may include an editing module 1132, a simulating module 1136, or a deploying module 1138. The editing module 1132 may be capable of exposing the configurable attributes of a component (e.g., widget 1 112 of
An Application Program Interface (API) server 1514 and a web server 1516 are coupled to, and provide programmatic and web interfaces respectively to, one or more application servers 1518. The application servers 1518 host one or more marketplace applications 1520 and payment applications 1522. The application servers 1518 are, in turn, shown to be coupled to one or more databases servers 1524 that facilitate access to one or more databases 1526.
The marketplace applications 1520 may provide a number of marketplace functions and services to users that access the networked system 1502. The payment applications 1522 may likewise provide a number of payment services and functions to users. The payment applications 1522 may allow users to 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 redeem the accumulated value for products (e.g., goods or services) that are made available via the marketplace applications 1520. While the marketplace and payment applications 1520 and 1522 are shown in
Further, while the system 1500 shown in
The web client 1506 accesses the various marketplace and payment applications 1520 and 1522 via the web interface supported by the web server 1516. Similarly, the programmatic client 1508 accesses the various services and functions provided by the marketplace and payment applications 1520 and 1522 via the programmatic interface provided by the API server 1514. The programmatic client 1508 may, for example, be a seller application (e.g., the TurboLister application developed by eBay Inc., of San Jose, Calif.) to enable sellers to author and manage listings on the networked system 1502 in an off-line manner, and to perform batch-mode communications between the programmatic client 1508 and the networked system 1502.
The networked system 1502 (
A number of fixed-price applications 1604 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 eBay Inc., of San Jose, Calif.) may be offered in conjunction with auction-format listings, 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 1606 allow a seller to group listings within a “virtual” store, which may be branded and otherwise personalized by and for the seller. Such a virtual store may also offer promotions, incentives and features that are specific and personalized to a relevant seller.
Reputation applications 1608 allow users that transact, utilizing the networked system 1502, to establish, build and maintain reputations, which may be made available and published to potential trading partners. Consider that where, for example, the networked system 1502 supports person-to-person trading, users may otherwise have no history or other reference information whereby the trustworthiness and credibility of potential trading partners may be assessed. The reputation applications 1608 allow a user (for example through feedback provided by other transaction partners) to establish a reputation within the networked system 1502 over time. Other potential trading partners may then reference such a reputation for the purposes of assessing credibility and trustworthiness.
Personalization applications 1610 allow users of the networked system 1502 to personalize various aspects of their interactions with the networked system 1502. For example a user may, utilizing an appropriate personalization application 1610, 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 1610 may enable a user to personalize listings and other aspects of their interactions with the networked system 1502 and other parties.
The networked system 1502 may support a number of marketplaces that are customized, for example, for specific geographic regions. A version of the networked system 1502 may be customized for the United Kingdom, whereas another version of the networked system 1502 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. The networked system 1502 may accordingly include a number of internationalization applications 1612 that customize information (and/or the presentation of information) by the networked system 1502 according to predetermined criteria (e.g., geographic, demographic or marketplace criteria). For example, the internationalization applications 1612 may be used to support the customization of information for a number of regional websites that are operated by the networked system 1502 and that are accessible via respective web servers 1516 (
Navigation of the networked system 1502 may be facilitated by one or more navigation applications 1614. In order to make listings available via the networked system 1502 as visually informing and attractive as possible, the marketplace and payment applications 1520 and 1522 may include one or more imaging applications 1616 which users may utilize to upload images for inclusion within listings. An imaging application 1616 also operates to incorporate images within viewed listings. The imaging applications 1616 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 1618 allow sellers to conveniently author listings pertaining to goods or services that they wish to transact via the networked system 1502, and listing management applications 1620 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 1620 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 1622 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 1602, a seller may wish to leave feedback regarding a particular buyer. To this end, a post-listing management application 1622 may provide an interface to one or more reputation applications 1608, so as to allow the seller to conveniently provide feedback regarding multiple buyers to the reputation applications 1608.
Dispute resolution applications 1624 provide mechanisms whereby disputes arising between transacting parties may be resolved. For example, the dispute resolution applications 1624 may provide guided procedures whereby the parties are guided through a number of operations 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 1626 implement fraud detection and prevention mechanisms to reduce the occurrence of fraud within the networked system 1502.
Messaging applications 1628 are responsible for the generation and delivery of messages to users of the networked system 1502. These messages may, for example, advise users regarding the status of listings at the networked system 1502 (e.g., providing “outbid” notices to bidders during an auction process or providing promotional and merchandising information to users). Respective messaging applications 1628 may utilize any one of a number of message delivery networks and platforms to deliver messages to users. For example, messaging applications 1628 may deliver electronic mail (e-mail), instant message (IM), Short Message Service (SMS), text, facsimile, or voice (e.g., Voice over IP (VoIP)) messages via the wired (e.g., the Internet), Plain Old Telephone Service (POTS), or wireless (e.g., mobile, cellular, WiFi, WiMAX) networks.
Merchandising applications 1630 support various merchandising functions that are made available to sellers to enable sellers to increase sales via the networked system 1502. The merchandising applications 1630 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 networked system 1502 itself, or one or more parties that transact via the networked system 1502, may operate loyalty programs that are supported by one or more loyalty/promotion applications 1632. For example, a buyer may earn loyalty or promotions points for each transaction established and/or concluded with a particular seller, and may be offered a reward for which accumulated loyalty points can be redeemed.Modules, Components and Logic
Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (e.g., code embodied on a machine-readable medium or in a transmission signal) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.
In various embodiments, a hardware module may be implemented mechanically or electronically. For example, a hardware module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
Accordingly, the term “hardware module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein. Considering embodiments in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where the hardware modules comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different hardware modules at different times. Software may accordingly configure a processor, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.
Hardware modules can provide information to, and receive information from, other hardware modules. Accordingly, the described hardware modules may be regarded as being communicatively coupled. Where multiple such hardware modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the hardware modules. In embodiments in which multiple hardware modules are configured or instantiated at different times, communications between such hardware modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware modules have access. For example, one hardware module may perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware module may then, at a later time, access the memory device to retrieve and process the stored output. Hardware modules may also initiate communications with input or output devices and can operate on a resource (e.g., a collection of information).
The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules.
Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or processors or processor-implemented modules. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors may be distributed across a number of locations.
The one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., APIs).Electronic Apparatus and System
Example embodiments may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Example embodiments may be implemented using a computer program product, e.g., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable medium for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.
A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
In example embodiments, operations may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method operations can also be performed by, and apparatus of example embodiments may be implemented as, special purpose logic circuitry, e.g., a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC).
The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In embodiments deploying a programmable computing system, it will be appreciated that that both hardware and software architectures require consideration. Specifically, it will be appreciated that the choice of whether to implement certain functionality in permanently configured hardware (e.g., an ASIC), in temporarily configured hardware (e.g., a combination of software and a programmable processor), or a combination of permanently and temporarily configured hardware may be a design choice. Below are set out hardware (e.g., machine) and software architectures that may be deployed, in various example embodiments.Example Machine Architecture and Machine-Readable Medium
The example computer system 1700 includes a processor 1702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory 1704 and a static memory 1706, which communicate with each other via a bus 1708. The computer system 1700 may further include a video display unit 1710 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 1700 also includes an alphanumeric input device 1712 (e.g., a keyboard), a user interface (UI) navigation (or cursor control) device 1714 (e.g., a mouse), a disk drive unit 1716, a signal generation device 1718 (e.g., a speaker) and a network interface device 1720.Machine-Readable Medium
The disk drive unit 1716 includes a machine-readable medium 1722 on which is stored one or more sets of instructions 1724 and data structures (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. The instructions 1724 may also reside, completely or at least partially, within the main memory 1704 and/or within the processor 1702 during execution thereof by the computer system 1700, the main memory 1704 and the processor 1702 also constituting machine-readable media. The instructions 1724 may also reside, completely or at least partially, within the static memory 1706.
While the machine-readable medium 1722 is shown in an example embodiment to be a single medium, the term “machine-readable medium” may 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 instructions 1724 or data structures. The term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present embodiments, or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media include non-volatile memory, including by way of example semiconductor memory devices, e.g., Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and compact disc-read-only memory (CD-ROM) and digital versatile disc (or digital video disc) read-only memory (DVD-ROM) disks.Transmission Medium
The instructions 1724 may further be transmitted or received over a communications network 1726 using a transmission medium. The instructions 1724 may be transmitted using the network interface device 1720 and any one of a number of well-known transfer protocols (e.g., Hyper Text Transfer Protocol or HTTP). Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), the Internet, mobile telephone networks, Plain Old Telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMax networks). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.
Although an embodiment 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 disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof, show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.
Such embodiments of the inventive subject matter may be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.
1. A system comprising:
- a call optimizer associated with an application running on an application server, the application including a plurality of components, the call optimizer comprising: an intercepting module to intercept a first call and a second call, the first call made to a service by a first one of the plurality of components and the second call made to the service by a second one of the plurality of components; and an orchestrating module to orchestrate the first call and the second call into a third call.
Filed: May 18, 2016
Publication Date: Sep 15, 2016
Inventors: Bin Ni (Fremont, CA), Diego Lagunas (San Jose, CA), Jun Lu (Sunnyvale, CA), Venu Reddy (San Jose, CA), Ramamurthy Kumar (Cupertino, CA), Sami Ben-Romdhane (San Jose, CA)
Application Number: 15/157,882