Building Web Reputation Systems- P23

Building Web Reputation Systems- P23:Today’s Web is the product of over a billion hands and minds. Around the clock andaround the globe, people are pumping out contributions small and large: full-lengthfeatures on Vimeo, video shorts on YouTube, comments on Blogger, discussions onYahoo! Groups, and tagged-and-titled Del.icio.us bookmarks. User-generated contentand robust crowd participation have become the hallmarks of Web 2.0.
Nội dung trích xuất từ tài liệu:
Building Web Reputation Systems- P23 message to the Yahoo! Profiles karma model without knowing the address for the dispatcher; it can just send a message to the one for its own framework and know that the message will get relayed to the appropriate servers. Note that a registration service, such as the one described for the dispatch consumer, is required to support this functionality.There can be many message dispatchers deployed, and this layer is a natural locationto provide any context-based security that may be required. Since changes to the rep-utation database come only by sending messages to the reputation framework, limitingapplication access to the dispatcher that knows the names and addresses of the context-specific models makes sense. As a concrete example, only Yahoo! Travel and Local hadthe keys needed to contact, and therefore make changes to, the reputation frameworkthat ran their shared model, but any other company property could read their ratingsand reviews using the separate reputation query layer (see “Reputation query inter-face” on page 298).The Yahoo! Reputation Platform’s dispatcher implementation was optimistic: allapplication API calls return immediately without waiting for model execution. Themessages were stored with the dispatcher until they could be forwarded to a modelexecution engine.The transport services used to move messages to the dispatcher varied by application,but most were proprietary high-performance services. A few models, such as Yahoo!Mail’s Spam IP reputation, accepted inputs on a best-effort basis, which uses the fastestavailable transport service. The Yahoo! Reputation Platform high-level architectural layer cake shown in Figure A-1 contains all the required elements of a typical rep- utation framework. New framework designers would do well to start with that design and design/select implementations for each component to meet their requirements.Model execution engine. Figure A-3 shows the heart of the reputation framework, themodel execution engine, which manages the reputation model processes and their state.Messages from the dispatcher layer are passed into the appropriate model code forimmediate execution. The model execution engine reads and writes its state, usuallyin the form of reputation statements via the reputation database layer. (See “Reputationrepository” on page 298.) Model processes run to completion, and if cross-modelexecution or optimism is desired, may send messages to the dispatcher for futureprocessing.The diagram also shows that models may use the external event signaling system tonotify applications of changes in state. See the section “External signaling inter-face” on page 297.296 | Appendix A: The Reputation FrameworkFigure A-3. Yahoo! Reputation Platform model engine.This platform gets much of its performance from parallel processing, and the Yahoo!Reputation Platform uses this approach by implementing an Engine Proxy that routesall incoming message traffic to the engine that is currently running the appropriatemodel in a concurrent process. This proxy is also in charge of loading and initializingany model that is not currently loaded or executing.The Yahoo! Reputation Platform implemented models in PHP with many of the mes-saging lines within the model diagram implemented as function calls instead of higher-overhead messages. See “Your Mileage May Vary” on page 300 for a discussion of therationale. The team chose PHP mostly due to its members’ personal expertise and tastes(there was no particular technical requirement that drove this choice).External signaling interface. In optimistic systems, such as the Yahoo! reputation platform,output happens passively: the application has no idea when a change happened or whatthe results were of any input event. Some unknown time after the input, a query to thedatabase may or may not reflect a change. In high-volume applications, this is a verygood thing because it is just impractical to wait for every side effect of every input to Framework Designs | 297propagate across dozens of servers. But when something important (read valuable)happens, such as an IP address switching from good-actor to spammer, the applicationneeds to be informed ASAP.This is accomplished by using an external signaling interface. For smaller systems, thiscan just be hardcoded calls in the reputation model implementation. But larger envi-ronments normally have signalling services in place that typically log signal details andhave mechanisms for executing processes that take actions, such as changing user ac-cess or contacting supervisory personnel.Another kind of signaling interface can be used to provide a layer of request-re ...