I had the privilege of briefly meeting Barack Obama at a fundraiser in early September. Seeing and hearing him speak first-hand stripped away all the layers of media and punditry that has made it so difficult to assess which candidate is best for our country. Meeting him not only confirmed for me that Obama is the best choice, it also confirmed for me that he has what it takes to be a great leader. One of the major epiphanies I had following the meeting centered around his economic plan: how it would impact me personally and how it would impact America as a nation if he executes his plan.
One of the many components of the Obama economic plan is to roll back the Bush tax cuts on the wealthiest Americans, back to the level they were under Bill Clinton. We happen to fall within this group, yet we fully support it. Why would we advocate a tax plan that costs us more money? Because it has a better return on investment than the alternative, which calls for further tax cuts despite rampant federal spending, thus putting the stability and security of our country at great risk. Let me begin with a crash course on federal budget economics.
Tax revenue is the primary source of income for the federal government. When it spends more than it receives, it has a budget deficit. To fund a deficit, it borrows money by issuing government bonds to domestic lenders and sovereign bonds to foreign lenders. These bonds are considered risk-free because the government can raise taxes, reduce spending, or even print more money if necessary to ensure the bond can be redeemed (paid back in full) at maturity.
Therefore, with a budget deficit, part of the tax revenue received is spent on interest payments to debt holders. New debt issued at higher interest rates due to inflation costs more. Interest payments made to foreign debt holders fluctuate in cost as the value of the US Dollar changes. This is because sovereign bonds are denominated in the foreign currency, and a cheaper dollar means more is required to convert to the currency for interest payments. The worst case scenario is when tax revenue decreases and spending increases over a long period of time, because it pushes national debt to levels that could be catastrophic to the economy and the value of our currency.
As of March 2008, our national debt was about $9.6 trillion dollars. $5.4 trillion was owned by the public. Public debt is lent by individuals, businesses, and both local and foreign governments. Almost half of this (over $2.6 trillion) is sovereign debt owned by foreign countries. Russia owned $60 billion, oil exporting nations owned $153 billion, and China owned a whopping $502 billion in US debt. Altogether, we spent more than $250 billion dollars in FY08 paying interest alone on our national debt. Only defense, Social Security, and Medicare cost more.
Since then, we’ve spent over $60 billion dollars in Iraq. The Bear Stearns bailout and nationalization of Fannie, Freddie, and AIG will cost more than $300 billion. Now Washington is asking for $700 billion more to absorb a fraction of the toxic debt behind the currently unfolding financial crisis. So we’re looking at more than a trillion dollars in additional national debt, and we haven’t even addressed the potential spending burden of the growing crises in Afghanistan, Pakistan, and Georgia!
As a result of all this spending, our national debt has surged to record levels. A year ago, Congress raised the debt limit to $9.8 trillion. In July, they raised it to $10.6 trillion. With the bailout package currently being legislated, it is now expected to rise to $11.3 trillion, and there appears to be nothing stopping it from going to $12 or $14 or even $15 trillion dollars in the next few years. This would be sustainable if tax revenue was growing with it, but it is not. Tax revenue is constrained by the high unemployment rate, lack of income growth, and by businesses that exploit loopholes or move revenue offshore. And the Republicans in power over most of the last seven years have been cutting taxes (i.e., reducing tax revenue) with the belief that it will stimulate the economy, which has further exacerbated the ballooning deficit and accumulating national debt.
Imagine you have a stable job and live in a house that you financed with a $400,000 loan from a bank in Canada. You pay your bills on time, generally paying more than the minimum on your credit card each month, but the balance has increased dramatically this year. One day you got throbbing toothache that required emergency dental surgery, but dental insurance only covered a fraction of the cost due to a high deductible. High gas prices have doubled how much you spend to get to and from work every day. The dental surgery, high gas prices, and general inflation have made it difficult for you to make even the minimum payment. And since the value of the US Dollar has dropped considerably, monthly payments on the Canadian loan have almost doubled because of required conversion to the Canadian Dollar.
Suddenly, you find yourself in a cash flow negative situation. You try to trade your car in for a more fuel-efficient model, but you don’t have the money saved up to make the down payment, nor the capacity for the monthly payments. You look for other ways to cut costs such cancelling memberships, turning the heat down in your house, use Netflix instead of going to the movies, and downgrade cable service, but it’s not enough. You explore refinancing your home loan and/or establishing a home equity line of credit, but your debt-to-equity ratio too low to qualify. The only alternative is to get another credit card, but due to inflation and a lower credit score from the existing credit card balance, the credit card has a high APR.
Now imagine a solution to your income problem taking the Republican approach: rather than ask for a raise or find another income source, you show up at work and ask for a salary cut. Your rationale is that it will allow your employer to develop more business, and thus it will increase your chances for an excellent review and higher annual bonus. Despite best wishes, less income only accelerates your descent into bankruptcy, so it is clearly not a feasible approach to take. Our federal government now finds itself in a similar conundrum: unforeseen natural disasters and economic problems, inflation, higher interest rates, and exposure to currency risk on foreign debt redemptions contribute to our ballooning national debt. It is not feasible for the federal government to do the equivalent of a salary cut and lower tax revenue in hopes that it will stimulate the economy.
The Obama economic plan calls for addressing this problem by optimizing both tax and spend to pull us out of this rapid descent into economic oblivion. Despite widespread belief, Obama’s plan does not raise taxes. Specifically, the plan states that if your family adjusted gross income is $90,000 or less, you’ll get tax cuts. If between $90,000 and $250,000, your income tax stays the same. Anybody above $250,000 gets rolled back to what it was under Clinton, which is 36% for the second highest tax bracket, and 39.6% for the highest tax bracket. Effectively, Obama is calling for distributing tax cuts given to high income taxpayers under the Bush administration to over 150 million taxpayers who fall below the top two income tax brackets.
Despite the fact that Obama calls for more of my money to be taken from me—money to feed my kids and put clothes on their backs, or perhaps go on a family vacation—I think it is an essential component to restoring economic stability. More money in the hands of those who really need it brings back that extra cappuccino, brings people out to the movies again, affords higher car payments for more fuel efficient automobiles, etc. 150 million people consuming more stimulates the economy by growing businesses whose additional sales results in more tax revenue for the very government who must reduce the federal budget deficit to avert major financial crisis. I’d rather suck it up with a moderate income tax increase than the alternative – watching everything I own go down the tubes along with the economy.
Friday, October 3, 2008
Friday, August 15, 2008
No Rest for the Wicked
Representational State Transfer (REST) is a popular architectural style used in the construction of systems whose components are distributed across a network. First conceived by Roy T. Fielding in his famous doctoral dissertation Architectural Styles and the Design of Network-based Software Architectures, REST as an architectural style has become popular through its application in Web architectures with three pervasive technologies: HTTP, XML, and URI.
Developers have embraced these technologies, which are elements of the Web architecture, as REST itself. The result, unfortunately, is that REST has now become synonymous with building applications that use HTTP to transfer XML representations of resources identified by URIs around a network. Developers are arguing the pros and cons of something wacky like tunneling SOAP-tunneled RMI calls with GET vs. POST as if it were a philosophy of REST problem! This is so way off the mark. While some of these ideas can be put to use in a way that results in well-designed systems, the problem is that developers jumped on the bandwagon too early and left behind the true nature and timeless value of the REST architectural style.
Bloggers seem to be saying that to be RESTful, you must transfer content around the system using HTTP GET, PUT, POST, and DELETE. You must identify resources with URIs, and representations of those resources must be transferred in XML. So here we go again: the Majors of the world have socially engineered the Boxer masses once again. But the solution doesn't always fit the problem, does it? One could argue that solutions never fit the problem - that it is a subjective notion. But true practitioners know what I mean. Solutions forced into problem contexts can quickly metastasize into poor architecture decisions and signal the beginning of a brutish Hobbesian future for REST proper, RESTful system development, and all those involved (or at least those who get blamed for it).
The classic problem rears its head once again. The business ends up committing far more time and resources than originally budgeted, and there is no going back. Critical design flaws emerge and the system becomes very costly to maintain. Well into production, when its progenitors are long gone, the remaining team struggles to maintain a poorly performing system that is difficult and frustrating to use. It is so brittle and hard-coded that, outside of the depressing task of maintenance, a complete rewrite is necessary. Unfortunately, many companies find themselves in this situation, and all of it could have been prevented if a little more thinking had gone into it before the project started. Instead, REST gets blamed as a past trend by sellers of the latest snake oils in the market.
Introduction to REST
REST is an architectural style comprised of a collection of recurring architectural themes that transcend the constraints of any specific set of technologies or protocols used to build a system. According to Fielding in section 5.2 of his dissertation, the REST style is an abstraction of the architectural elements within a distributed hypermedia system.
REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements.
The Web architecture is a single application—just one of infinitely possible examples—of the REST architectural style. To dig a little deeper into what this means, let's explore the metaphysics of REST, look at a message passing architecture as another example of applied REST, and then use parts of Fielding's dissertation and subsequent writings to show beyond a reasonable doubt that I'm not completely off my rocker.
REST as Applied Perdurantism
Okay, okay, don't let the word scare you away. Resources are a key abstraction in the REST style. More specifically, a resource R is a temporally varying member function MR(t), which at time t maps to a set of values. The values are resource representations and/or identifiers. See? No mention of XML files on Web servers or HTTP to communicate representations of them. Great, this is music to my ears! I happen to be a fan of the school of metaphysical perdurantism. Just like Web architecture is applied REST, REST is applied perdurantism. Let's waste a little time exploring this concept further.
The idea behind perdurantism is that material objects extend through space and are identified by having different spatial parts in different places, and they also persist via temporal parts that extend through time. So objects are like four-dimensional entities comprised of parts that take up the three dimensions of space, and the collection of these spatial parts at any given point in time comprise the time dimension.
Object identity takes on an interesting characteristic with this approach: noticeable changes in the set of spatial parts making up an object at any given instant could be indexed over time and identified via epochs. So under perdurantism, person X from moment of conception until wisdom teeth are extracted, and person X from that point until now are considered the same person, despite the fact that many changes have occurred before, during, and after the extraction.
How about an example that doesn't make you cringe: a piece of code known as Foo.java from conception through all its revisions to the most recent version maintains the same identity. We still call it Foo.java. To reference a specific revision or epoch is what Fielding is getting at with his "temporally varying member function MR(t), where revision r or time t maps to a set of spatial parts" stuff. In short, line 15 of Foo.java is just as much a part as version 15 of Foo.java, they just reference different subsets of its set of parts (one spatial and one temporal).
How does this concept apply to resources in REST? Resources are a composite of the set of all spatiotemporal parts for a material object, and representations are immutable reflections on a subset of the set of parts that have identity in a resource, and whose content can take on different forms when transferred between components. Moreover, resource identifiers are abstractions that allow components involved in a transfer to identify and select subsets of the resource's parts to be transferred.
Looking back at section 5.2 of the dissertation, Fielding says a resource identifier is used to identify the particular resource involved in an interaction between components. Rather than enforce a particular standard, the author chooses a resource identifier that best fits the nature of the concept being identified. So maybe the author chooses to identify line 15 from the Foo.java file resource as Foo.java#15 and version 15 of Foo.java as Foo.java?v=15.
This fits nicely with perdurance, since each resource has its own composition of spatial and temporal parts that can be identified. Components exchanging representations of these resources need a priori knowledge of the resource and how to identify parts of it. While REST does not mandate use of a particular standard, use of the URI as a standard for identification is certainly useful, especially since its adoption is somewhat universal and has far transcended the Web.
There is an ongoing debate in the philosophical community about the notion of an object, its parts, and identity in terms of perdurantism vs. other competing schools such as endurantism. Discourse is not limited to architectural styles in building distributed systems, nor are they limited to objects materially comprised of atoms, bits, or any hybrid thereof.
Just as the REST architectural style for distributed systems can be seen as an application of perdurantism, and just as the Web architecture is an application of REST, a message passing architecture can be an application of REST as well.
Message Passing Architecture as Applied REST
Message passing architectures, also referred to as publish-subscribe or pub/sub architectures, have become popular over the years in large, event-driven distributed applications. Rather than require components to actively identify and pull representations of resources from other components, the data is more efficiently pushed out to them based on a previously established indication of interest, usually via subscription. We'll use this as our non-Web example of applied REST.
Subscribers typically subscribe to a subject (i.e., the resource identifier), and publishers publish notifications, events, or data updates through this subject. An example would be a real-time market data feed, where the subject is composed of segments that identify a particular spatial part of the service (e.g., execution venue and symbol), and temporal parts published are real-time quote and trade data updates. Some publishers, especially those providing trade and quote feed services, communicate session-level sequence numbers and allow subscribers to submit sequence inquiries if updates are missed.
This message passing architecture can meet the constraints of the REST architectural style. Fielding's dissertation provides web examples. Let us look at the architectural elements of REST and explore some examples for our message passing architecture:
Data Elements
Conclusion
The above should provide enough substance to show that a message passing architecture can fit within the constraints of the REST architectural style. Sure, we can perform an exhaustive analysis of the actual constraints and confirm that the above architecture conforms, however my focus is not REST purity. It's exploring how distributed systems can be architected using the REST style. If you have any doubt remaining, look at what Fielding himself has to say about this topic.
In future blog postings, I hope to explore this message passing architecture in the form of a content-based router as an example that transfers representations between REST components as a key component of a RESTful architecture that has no dependency on HTTP GET or POST. I'll address how requests for representations are queued and dispatched to request handlers and how representations are published to interested subscribers without jumping on the REST bandwagon and misusing the REST architectural style through the confines of the Web architecture.
Developers have embraced these technologies, which are elements of the Web architecture, as REST itself. The result, unfortunately, is that REST has now become synonymous with building applications that use HTTP to transfer XML representations of resources identified by URIs around a network. Developers are arguing the pros and cons of something wacky like tunneling SOAP-tunneled RMI calls with GET vs. POST as if it were a philosophy of REST problem! This is so way off the mark. While some of these ideas can be put to use in a way that results in well-designed systems, the problem is that developers jumped on the bandwagon too early and left behind the true nature and timeless value of the REST architectural style.
Bloggers seem to be saying that to be RESTful, you must transfer content around the system using HTTP GET, PUT, POST, and DELETE. You must identify resources with URIs, and representations of those resources must be transferred in XML. So here we go again: the Majors of the world have socially engineered the Boxer masses once again. But the solution doesn't always fit the problem, does it? One could argue that solutions never fit the problem - that it is a subjective notion. But true practitioners know what I mean. Solutions forced into problem contexts can quickly metastasize into poor architecture decisions and signal the beginning of a brutish Hobbesian future for REST proper, RESTful system development, and all those involved (or at least those who get blamed for it).
The classic problem rears its head once again. The business ends up committing far more time and resources than originally budgeted, and there is no going back. Critical design flaws emerge and the system becomes very costly to maintain. Well into production, when its progenitors are long gone, the remaining team struggles to maintain a poorly performing system that is difficult and frustrating to use. It is so brittle and hard-coded that, outside of the depressing task of maintenance, a complete rewrite is necessary. Unfortunately, many companies find themselves in this situation, and all of it could have been prevented if a little more thinking had gone into it before the project started. Instead, REST gets blamed as a past trend by sellers of the latest snake oils in the market.
Introduction to REST
REST is an architectural style comprised of a collection of recurring architectural themes that transcend the constraints of any specific set of technologies or protocols used to build a system. According to Fielding in section 5.2 of his dissertation, the REST style is an abstraction of the architectural elements within a distributed hypermedia system.
REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements.
The Web architecture is a single application—just one of infinitely possible examples—of the REST architectural style. To dig a little deeper into what this means, let's explore the metaphysics of REST, look at a message passing architecture as another example of applied REST, and then use parts of Fielding's dissertation and subsequent writings to show beyond a reasonable doubt that I'm not completely off my rocker.
REST as Applied Perdurantism
Okay, okay, don't let the word scare you away. Resources are a key abstraction in the REST style. More specifically, a resource R is a temporally varying member function MR(t), which at time t maps to a set of values. The values are resource representations and/or identifiers. See? No mention of XML files on Web servers or HTTP to communicate representations of them. Great, this is music to my ears! I happen to be a fan of the school of metaphysical perdurantism. Just like Web architecture is applied REST, REST is applied perdurantism. Let's waste a little time exploring this concept further.
The idea behind perdurantism is that material objects extend through space and are identified by having different spatial parts in different places, and they also persist via temporal parts that extend through time. So objects are like four-dimensional entities comprised of parts that take up the three dimensions of space, and the collection of these spatial parts at any given point in time comprise the time dimension.
Object identity takes on an interesting characteristic with this approach: noticeable changes in the set of spatial parts making up an object at any given instant could be indexed over time and identified via epochs. So under perdurantism, person X from moment of conception until wisdom teeth are extracted, and person X from that point until now are considered the same person, despite the fact that many changes have occurred before, during, and after the extraction.
How about an example that doesn't make you cringe: a piece of code known as Foo.java from conception through all its revisions to the most recent version maintains the same identity. We still call it Foo.java. To reference a specific revision or epoch is what Fielding is getting at with his "temporally varying member function MR(t), where revision r or time t maps to a set of spatial parts" stuff. In short, line 15 of Foo.java is just as much a part as version 15 of Foo.java, they just reference different subsets of its set of parts (one spatial and one temporal).
How does this concept apply to resources in REST? Resources are a composite of the set of all spatiotemporal parts for a material object, and representations are immutable reflections on a subset of the set of parts that have identity in a resource, and whose content can take on different forms when transferred between components. Moreover, resource identifiers are abstractions that allow components involved in a transfer to identify and select subsets of the resource's parts to be transferred.
Looking back at section 5.2 of the dissertation, Fielding says a resource identifier is used to identify the particular resource involved in an interaction between components. Rather than enforce a particular standard, the author chooses a resource identifier that best fits the nature of the concept being identified. So maybe the author chooses to identify line 15 from the Foo.java file resource as Foo.java#15 and version 15 of Foo.java as Foo.java?v=15.
This fits nicely with perdurance, since each resource has its own composition of spatial and temporal parts that can be identified. Components exchanging representations of these resources need a priori knowledge of the resource and how to identify parts of it. While REST does not mandate use of a particular standard, use of the URI as a standard for identification is certainly useful, especially since its adoption is somewhat universal and has far transcended the Web.
There is an ongoing debate in the philosophical community about the notion of an object, its parts, and identity in terms of perdurantism vs. other competing schools such as endurantism. Discourse is not limited to architectural styles in building distributed systems, nor are they limited to objects materially comprised of atoms, bits, or any hybrid thereof.
Just as the REST architectural style for distributed systems can be seen as an application of perdurantism, and just as the Web architecture is an application of REST, a message passing architecture can be an application of REST as well.
Message Passing Architecture as Applied REST
Message passing architectures, also referred to as publish-subscribe or pub/sub architectures, have become popular over the years in large, event-driven distributed applications. Rather than require components to actively identify and pull representations of resources from other components, the data is more efficiently pushed out to them based on a previously established indication of interest, usually via subscription. We'll use this as our non-Web example of applied REST.
Subscribers typically subscribe to a subject (i.e., the resource identifier), and publishers publish notifications, events, or data updates through this subject. An example would be a real-time market data feed, where the subject is composed of segments that identify a particular spatial part of the service (e.g., execution venue and symbol), and temporal parts published are real-time quote and trade data updates. Some publishers, especially those providing trade and quote feed services, communicate session-level sequence numbers and allow subscribers to submit sequence inquiries if updates are missed.
This message passing architecture can meet the constraints of the REST architectural style. Fielding's dissertation provides web examples. Let us look at the architectural elements of REST and explore some examples for our message passing architecture:
Data Elements
- Resource: order, basket, order book, trade, trade blotter, execution report, symbol, montage, exchange, NBBO, etc.
- Resource Identifier: URI to identify the spatiotemporal "shape" of data to be transferred between components, as a subset of all parts that comprise a given resource.
- Resource Metadata: caching semantics, version info, sequence number, identity of new resource, content type mappings; made available in a metadata directory service that exists in a system configuration manager.
- Representation: full initial or current data snapshots; delta updates communicated to subscribers; updates with before and after images that include in and/or out of focus disposition.
- Representation Metadata: content type, sending time, sequence number, checksum, encryption method, content length, etc.
- Control Data: message type, computer or location identifier for sender or target (or any intermediate component in between), retransmission semantics such as possible duplicate, possible resend, original sending time, last sequence number processed.
- Client: facilitates connectivity for initiator of communication such as a subscriber or requester; hides details such as use of connection retry policies to handle reconnects.
- Server: same as client connector, except facilitates connectivity for receiver of client communication such as a publisher or request handler.
- Cache: located in both the client and server to reduce latency for data dependencies that require injection of external content to send or process requests.
- Resolver: resolves computer or location identifiers into IP addresses and ports of target or intermediate components.
- Tunnel: SOCKS proxy creates an SSL tunnel to a message router on behalf of any clients behind a firewall.
- User Agent: initiator of communication such as front-end GUIs for front office sales & position traders, middle office, system administrators, and test simulators.
- Proxy: instance of a content-based router selected by initiator components to broker queued requests or perform pub/sub message routing.
- Gateway: sits within same physical machine as the origin server and encapsulates process configuration and management of fail-over routing of content to backup message routers as well as routing requests to be processed by components operating at various nice levels.
- Origin Server: the ultimate resource managers such as the system configuration manager, order manager, position manager, master blotter, market data server, market manager, etc.
Conclusion
The above should provide enough substance to show that a message passing architecture can fit within the constraints of the REST architectural style. Sure, we can perform an exhaustive analysis of the actual constraints and confirm that the above architecture conforms, however my focus is not REST purity. It's exploring how distributed systems can be architected using the REST style. If you have any doubt remaining, look at what Fielding himself has to say about this topic.
In future blog postings, I hope to explore this message passing architecture in the form of a content-based router as an example that transfers representations between REST components as a key component of a RESTful architecture that has no dependency on HTTP GET or POST. I'll address how requests for representations are queued and dispatched to request handlers and how representations are published to interested subscribers without jumping on the REST bandwagon and misusing the REST architectural style through the confines of the Web architecture.
Subscribe to:
Posts (Atom)
Posts
