[
Lists Home |
Date Index |
Thread Index
]
> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
<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.
|
