|
|
| Line 1: |
Line 1: |
| − | == Summary ==
| + | The CloudFree Platform will support a context sensitive runtime. Several |
| − | | + | constraints are not static. A context binds constraints to the current |
| − | A common concept of on-line shop systems is to have store items which
| + | execution. The contextual runtime is one of the key elements of the |
| − | represent products. Even some shop systems work with products directly.
| + | CloudFree platform. |
| − | In the auction world this is similar. There are various reasons for
| + | |
| − | decoupling the store items from the products most notably being design
| + | |
| − | driven (separation of concerns) and performance.
| + | |
| − | | + | |
| − | The listing story presented here is a based on the same basic | + | |
| − | principles. However, the concept proposed in this document goes beyond
| + | |
| − | these principles and creates a full-fledged listing store which is
| + | |
| − | suitable for serving auction sites as well as classic storefronts and
| + | |
| − | can be extended for any other scenario.
| + | |
| − | | + | |
| − | It's also essential to note that the listing story is deeply integrated
| + | |
| − | with search. Actually, search will be the only way to retrieve listings
| + | |
| − | from the underlying store. Traditional browsing will be possible by
| + | |
| − | filtering.
| + | |
| − | | + | |
| − | Following the CloudFree approach the listing service provides a common
| + | |
| − | interface for storefront/auction (i.e., web site) developers and hides
| + | |
| − | the complexity from them.
| + | |
| − | | + | |
| − | | + | |
| − | == The Listings ==
| + | |
| − | | + | |
| − | The listings are the core elements in this story. The can represent
| + | |
| − | products for sale on a storefront or items for sale in an auction.
| + | |
| − | However, the key is that they are not limited to those two
| + | |
| − | possibilities. Basically, a listing can by anything that you want to
| + | |
| − | present in some way to somebody. It's also possible that listings are
| + | |
| − | digital goods which can be downloaded or simply texts which can be
| + | |
| − | viewed on-line.
| + | |
| − | | + | |
| − | Therefore, listings do not provide a fixed structure. They are
| + | |
| − | unstructured documents consisting of a bunch of simple name-value
| + | |
| − | attributes. The attributes describe the listing further.
| + | |
| − | | + | |
| − | | + | |
| − | == Base Listing Attributes ==
| + | |
| − | | + | |
| − | In order to provide a common infrastructure for working with listings
| + | |
| − | the following attributes will be defined as the base attribtes.
| + | |
| − | | + | |
| − | * <code>id</code>
| + | |
| − | * <code>name</code>
| + | |
| − | * <code>title</code>
| + | |
| − | * <code>description</code>
| + | |
| − | | + | |
| − | <code>id</code> .. a machine generated unique identifier of a listing. It's purpose
| + | |
| − | is to locate a single specific listing if necessary.
| + | |
| − | | + | |
| − | <code>name</code> .. a human-readable name of a listing which is typically an
| + | |
| − | identifier that makes sense in a given context (eg. a product/sku
| + | |
| − | number)
| + | |
| − | | + | |
| − | <code>title</code> .. a human-readable listing title
| + | |
| − | | + | |
| − | <code>description</code> .. a human-readable description of the listing
| + | |
| − | | + | |
| − | All other listing attributes are specific to the context where the
| + | |
| − | listing is being used. For example, a "price" attribute can be used for
| + | |
| − | listing in a classic storefront to represent the actually item price.
| + | |
| − | However, in an auction site the "price" attribute can represent a "Buy
| + | |
| − | Now" price.
| + | |
| − | | + | |
| − | | + | |
| − | == Navigational Attributes ==
| + | |
| − | | + | |
| − | It is assumed that listings can be navigated. In order to make the
| + | |
| − | navigation as flexible as possible it will be based on the listing
| + | |
| − | attributes as well. Therefore, the following attributes will be used for
| + | |
| − | navigation.
| + | |
| − | | + | |
| − | * <code>path</code>
| + | |
| − | * <code>uripath</code>
| + | |
| − | * <code>tags</code>
| + | |
| − | * <code>start</code>
| + | |
| − | * <code>end</code>
| + | |
| − | | + | |
| − | <code>path</code> .. path a listing is contained in (eg. "folder/sub/subsub").
| + | |
| − | Note, the complete path is used here in order to have an implicit
| + | |
| − | assignment to the parent path as well. A listing may be attached to
| + | |
| − | multiple paths. In this case, multiple path attributes may be used. If a
| + | |
| − | path for a listing cannot be determined it will be listed in the root
| + | |
| − | path (i.e. '/').
| + | |
| − | | + | |
| − | <code>uripath</code> .. a URI path portion for direct lookup of listings. This is
| + | |
| − | useful for building search engine friendly site URLs. The URI does not
| + | |
| − | need to be unique across the board but should be unique within the same
| + | |
| − | lookup context (eg. unique across all auction listings of a site). Thus,
| + | |
| − | it will be interpreted relative to the context base. If the uri is not
| + | |
| − | provided it will be computed based on the title attribute. If no title
| + | |
| − | attribute is available the name attribute will be used with a last
| + | |
| − | fall-back to the listing id. URI must not start or end with a slash
| + | |
| − | ('/'). Note, the URI path is not encoded but contains the raw string as
| + | |
| − | entered by a user.
| + | |
| − | | + | |
| − | <code>tags</code> .. tags (aka. labels) attached to a listing. This allows to navigate
| + | |
| − | listings through a tag cloud or to filter based on tags. Tags are
| + | |
| − | optional.
| + | |
| − | | + | |
| − | <code>start</code> .. a timestamp which represents the time after which a listing
| + | |
| − | should be visible (UTC; yyyyMMddHHmm, eg. 200801311200). If the start
| + | |
| − | timestamp cannot be determined it will be set to "0" to make the listing
| + | |
| − | visible as soon as possible.
| + | |
| − | | + | |
| − | <code>end</code> .. a timestamp which represents the time after which a listing
| + | |
| − | should not be visible anymore (UTC; yyyyMMddHHmm, eg. 201012312359). If
| + | |
| − | the end timestamp cannot be determined it will be set to "0" which will
| + | |
| − | to make the listing visible forever.
| + | |
| − | | + | |
| − | | + | |
| − | == Performance ==
| + | |
| − | | + | |
| − | Performance is an important design goal. The most important thing to
| + | |
| − | note is that under all circumstances listing display time must be cheap
| + | |
| − | (read: flying fast). In order to achieve this we will aggregate as much
| + | |
| − | data as possible in listing attributes and move any computing and
| + | |
| − | aggregation into the listing generation process.
| + | |
| − | | + | |
| − | The general strategy is that listings will be generated from underlying
| + | |
| − | data on specific events. Additionally, all listing attributes will be
| + | |
| − | attached to a listing prior to making it available. We specifically
| + | |
| − | trade in actuality for performance, i.e. all updates to the underlying
| + | |
| − | data will be reflected on the listing only after an event has been
| + | |
| − | triggered to update the listing as well and only after the listing
| + | |
| − | update process has finished. The reason is that the listing update
| + | |
| − | process is considered to be expensive.
| + | |
| − | | + | |
| − | Even through the listing process is considered to be expensive it still
| + | |
| − | has to scale. Therefore, any implementation must be able to scale
| + | |
| − | horizontally. The listing generation process will process items in
| + | |
| − | parallel and be able to leverage a computing grid in order to scale.
| + | |
| − | | + | |
| − | It is important that during listing generation really all possible data
| + | |
| − | is aggregated into the listing. For example, if during a promotion
| + | |
| − | discounts are granted to a product the discount will be calculated
| + | |
| − | during the listing generation process. Additionally, the applied
| + | |
| − | discounts will be attached to the listing so that a storefront can
| + | |
| − | simply read the info from the listing without issuing an additional
| + | |
| − | lookup for discounts and without additional computations. Of course,
| + | |
| − | this is only possible with product discounts but not with order-time
| + | |
| − | discounts. However, following this philosophy it's also possible to
| + | |
| − | aggregate promotional information (eg., buy three get one free) into the
| + | |
| − | listing which would safe additional lookups during basket calculation.
| + | |
| − | | + | |
| − | | + | |
| − | == Real-Time Trade-Off ==
| + | |
| − | | + | |
| − | When real-time information needs to be displayed the listing story needs
| + | |
| − | to make an exception to the performance goal. The underlying assumption
| + | |
| − | is that any real-time service is performant and scalable to query. Very
| + | |
| − | likely, the real-time service will use a short cache for handling peak
| + | |
| − | loads. Based on this assumption it is further assumed that using the
| + | |
| − | real-time service directly is more efficient than performing frequent
| + | |
| − | invocations of the listing update process which is simply not designed
| + | |
| − | to handle real-time updates.
| + | |
| − | | + | |
| − | One example is the auction pricing model. The auction pricing model
| + | |
| − | requires real-time bid information to be present on an auction listing.
| + | |
| − | Therefore, the auction pricing *will* perform an additional lookup for
| + | |
| − | the bid information on a listing details page. Further performance
| + | |
| − | investigations will show if it's eventually possible to avoid the
| + | |
| − | additional lookups on listings browsing pages. However, the current
| + | |
| − | assumption is that the bidding service will provide this information in
| + | |
| − | a performant and scalable manner even for listing browsing pages which
| + | |
| − | would be more efficient than performing frequent invocations of the
| + | |
| − | listing update process.
| + | |
| − | | + | |
| − | Another example is inventory availability in an on-line shop. It's a
| + | |
| − | common functionality these days to indicate if an item is available and
| + | |
| − | can be shipped immediately (i.e., "on stock") or if there is a delay or
| + | |
| − | even sold out.
| + | |
| − | | + | |
| − | Of course, following the CloudFree approach the site developer will not
| + | |
| − | recognize the complexity behind this. A site developer will just query
| + | |
| − | the listing service and the listing service implementation will query
| + | |
| − | the listing store and any real-time service if necessary.
| + | |
| − | | + | |
| − | | + | |
| − | == Storage ==
| + | |
| − | | + | |
| − | The power of the listing story relies in the listing store. It is
| + | |
| − | assumed that the listing store will be capable of hosting all listings
| + | |
| − | and allows to query for listings very quickly. The listing store an be
| + | |
| − | compared to an index. It needs to provide query and filter capabilities.
| + | |
| − | The listing store shall also provide faceting capabilities. The listings
| + | |
| − | returned by the listing store will contain all the stored attributes.
| + | |
| − | The result has to be paged. The maximum listings per page shall be
| + | |
| − | reasonable low.
| + | |
| − | | + | |
| − | The storage itself will be pluggable supporting various client needs and
| + | |
| − | future growth. One store might be build upon open source search
| + | |
| − | technology like Apache Solr. Another store might be a commercial one
| + | |
| − | based on commercial offerings such as FAST or FACT-Finder.
| + | |
The CloudFree Platform will support a context sensitive runtime. Several
constraints are not static. A context binds constraints to the current
execution. The contextual runtime is one of the key elements of the
CloudFree platform.
