Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Mark Marchukov

dblp:62/3504 · DBLP profile ↗
← Back
4ranked-venue papers
0as first author
0since 2021 · last 2013
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 2Systems, architecture and hardware · 1Databases, data management, data science and information retrieval · 1

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Databases, data mining, and information retrieval
2 papers
Graph data management · 62% Distributed and cloud data management · 29% Data models and query languages · 9%
Computer architecture, parallel and distributed computing, and storage systems
1 paper
Storage systems · 77% Cloud and datacenter computing · 23%
Software engineering, system software, and programming languages
2 papers
Requirements engineering and software design · 100%

Topics — the 4 heaviest of 8, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Storage systems
distributed storage
0.212013
TAO: Facebook's Distributed Data Store for the Social Graph · USENIX ATC 2013
Cloud and datacenter computing
datacenter storage
0.012013
TAO: Facebook's Distributed Data Store for the Social Graph · USENIX ATC 2013
Requirements engineering and software design
software architecture
0.021999
Analysis of a Conflict between Aggregation and Interface Negotiation in Microsoft's Component Object Model · IEEE Trans. Software Eng. 1999
Using Formal Methods to Reason about Architectural Standards · ICSE 1997
Requirements engineering and software design › software architecture › component-based software engineering
component integration
0.011999
Analysis of a Conflict between Aggregation and Interface Negotiation in Microsoft's Component Object Model · IEEE Trans. Software Eng. 1999

Methods — techniques the papers use, named apart from their topics

distributed implementation · 0.1formal analysis · 0.0review validation · 0.0formal theory · 0.0formal methods · 0.0
YearPublicationVenuePosition
2013 TAO: Facebook's Distributed Data Store for the Social Graph
Nathan Bronson, Zach Amsden, George Cabrera, Prasad Chakka, Peter Dimov, Jack Ferris, Anthony Giardullo, Sachin Kulkarni, Harry C. Li, Mark Marchukov, Dmitri Petrov, Lovro Puzar, Yee Jiun Song, Venkateshwaran Venkataramani
USENIX ATC11
2012 TAO: how facebook serves the social graph
abstract
Over 800 million people around the world share their social interactions with friends on Facebook, providing a rich body of information referred to as the social graph. In this talk, I describe how we model and serve this graph. Our model uses typed nodes (fbobjects) and edges (associations) to express the relationships and actions that happen on Facebook. We access the graph via a simple API that provides queries over the set of same-typed associations leaving an object. We have found this API to be both sufficiently expressive and amenable to a scalable implementation. In the last segment of the talk I describe the design of TAO, our graph data store. TAO is a distributed implementation of the fbobject and association API that has been serving production traffic at Facebook for more than 2 years.
Venkateshwaran Venkataramani, Zach Amsden, Nathan Bronson, George Cabrera, Prasad Chakka, Peter Dimov, Jack Ferris, Anthony Giardullo, Jeremy Hoon, Sachin Kulkarni, Nathan Lawrence, Mark Marchukov, Dmitri Petrov, Lovro Puzar
SIGMOD Conference13
1999 Analysis of a Conflict between Aggregation and Interface Negotiation in Microsoft's Component Object Model
abstract
Many software projects today are based on the integration of independently designed software components that are acquired on the market, rather than developed within the projects themselves. A component standard, or integration architecture, is a set of design rules meant to ensure that such components can be integrated in defined ways without undue effort. The rules of a component standard define, among other things, component interoperability and composition mechanisms. Understanding the properties of such mechanisms and interactions between them is important for the successful development and integration of software components, as well as for the evolution of component standards. The paper presents a rigorous analysis of two such mechanisms: component aggregation and dynamic interface negotiation, which were first introduced in Microsoft's Component Object Model (COM). We show that interface negotiation does not function properly within COM aggregation boundaries. In particular, interface negotiation generally cannot be used to determine the identity and set of interfaces of aggregated components. This complicates integration within aggregates. We provide a mediator-based example, and show that the problem is in the sharing of interfaces inherent in COM aggregation.
Kevin J. Sullivan, Mark Marchukov, John Socha
IEEE Trans. Software Eng.2
1997 Using Formal Methods to Reason about Architectural Standards
abstract
We present a study in which we used formal methods to reason precisely about aspects of a widely used software architectural standard, namely Microsoft's Component Object Model (COM).We developed a formal theory of COM to help us reason about a proposed compositional architectural style based on COM, intended for use in a novel commercial multimedia authoring system.The style combined COM objects, integration mediators, and the COM reuse mechanism of aggregation.Our use of formal methods averted an architectural disaster by revealing essential but subtle and counterintuitive properties of COM.We partially validated our theory by subjecting it to review by the designers of COM and by testing it against other available data.The theory has good evidential support.
Kevin J. Sullivan, John Socha, Mark Marchukov
ICSE3