RE: RE: A Two Day Workshop for Software Architects
> From: Bullard, Claude L (Len) [mailto:clbullar@i...] <snip/> > 1. Please define scale. I don't think there is one hard and fast definition. It's largely a question of perspective. But I tend to think of things in terms of a desktop, a workgroup, a department, an enterprise, and a global network (the internet). Surely you would not argue that the models and patterns that work in one context can be automatically generalized across all of these contexts, would you? One OO principle that gets thrown about quite a bit is the notion of colocating code with the data it acts upon, and hiding that data from the outside. Some have argued that this is an area where OO got it wrong. They are wrong. They are simply generalizing a caricature of an OO pattern too far. As soon as I started writing distributed systems with OO, I moved toward patterns where I used lightweight objects that represented externalized state. Note that this did not violate encapsulation (or information hiding, to use the historical term that Betrand Meyer also prefers) as some have claimed. I did not have services spitting out data pertinent to their internal implementation details. I had them exchanging objects that were specifically crafted as part of their interface contract. And I adapted the patterns I used in development to suit the larger scale. When we tried to share information across the enterprise, we ran into cultural and political barriers. Some groups used Oracle tools, some used Microsoft tools, some were doing quite a bit with Perl scripts, while I was using OO 4GL tools at the time. Scaling OO across the enterprise would have meant forcing some technological diktat down everyone's throats that could have had the side effect of undermining efforts of some groups to solve an internal business problem for which a particular technology proved particularly well suited. So we focusing on messaging patterns and data warehousing as the way to share information across the enterprise. That worked pretty well. We adapted our patterns and approaches to address that scale, taking into account the additional political and cultural factors that came into play when trying to address that larger scale. > 2. If REST is the solution for Internet scale, why? > I suspect again, the number of axes of problems it > tries to solve are limited. If later, we find there are more > dimensions to what it is applied to, eg, web services, > will it still scale? If you have something better, offer it up. I would never be so presumptious as to think that we have heard the last word on this, yet. I just haven't heard anything better, yet. Some web applications won't really need all that REST provides. That's OK. But when I look at the sort of systems I've done, where everything is modeled as business objects, REST offers the right way for such a system to reach across the boundaries of the enterprise. I used to believe IIOP would be the answer to this, but it never took off. REST seems to me to be the answer... until something better comes along. OO strove to separate interfaces from implementation details. But those interfaces never completely broke free from implementations, and every effort to scale OO to the enterprise and beyond ran afoul of vendor wars. HTTP is ubiquitous. Do you want to fight the battle to get something else ubiquitously deployed in its stead? I don't. The key differences between REST and an OO-centric distributed architecture, as far as I can tell, are: REST uses URIs for addressing, rather than opaque handles tied to a particular ORB. REST uses hyperlinked documents for state representation rather than objects. REST relies upon a genericity of methods for large-scale interactions rather than type-bound methods. These things work quite well with HTTP. OO types don't. In the book "CORBA Design Patterns" that I previously mentioned, there is an interesting discussion regarding the challenge of getting types to extend beyond the enterprise. Types were too tightly bound to particular technical implementations. To understand one system's types, you needed to install software on the client. CORBA made a valiant effort to overcome this, with IORs for addressing, with generic invocation mechanisms, with facilities for trying to deal with types in a generic fashion. In the discussion on these matters, "CORBA Design Patterns" at one point makes the passing remark that "it must be acknowledged that this problem has not been adequately addressed". REST seems to offer an awfully compelling solution to circumvent this whole problem. I'm sold, but I'm still open to something better if anyone has a better way. I think it is obvious, though, that OO does not have the answers, here. I say this even though I am an ardent defender and advocate of OO. Nothing here invalidates OO. But OO does not have all of the answers. There are some problems it addresses quite well, but there are some for which it has no answers. Will REST prove to be inadequate? Maybe. If so, I hope that something better comes along. But when I look at the web systems I've done in the past, I wish now I had the map and compass that REST can provide. It would have been a useful guide for me in my design decisions. OO did not give me an adequate framework for such decisions, and it still doesn't. REST+hypermedia+OO+relational DBs... that's a pretty powerful toolset. Hybridized solutions will continue to dominate, just as you said in an earlier post. Some solutions won't need all of these, but architecture is a great guide in making such decisions.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format