[
Lists Home |
Date Index |
Thread Index
]
From: Michael Brennan [mailto:Michael_Brennan@Allegis.com]
> 1. Please define scale.
>I don't think there is one hard and fast definition. It's largely a question
>of perspective.
Then without the axis of perspective, the term scale is potentially
chaotic (indeterminate address). So when we use the term 'scale'
without the bounding axes, we add noise. Again, that is why I
asked some time ago, "what is The Web?" because one needs bounding
axes. My interest there is in determining what complexities REST
engenders and where they are handled.
>But I tend to think of things in terms of a desktop, a
>workgroup, a department, an enterprise, and a global network (the internet).
Ok. That skips over "The Web" though. It is not "the internet".
Also, while we can agree on those perspectives, we may discover
they don't match in other systems. For example, we have "agencies"
and although I think that might be "enterprise", it might not. It
seems trivial, but I see these as bounded systems, bounded by policies,
interfaces, document types handled, processes, and so on. Until one
has those boundaries well and clearly and inarguably named, we work
with a noisy description.
>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?
Most assuredly not.
>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.
I agree with you. Some confuse messages and documents with OOP objects.
Implementation can be separated from data for the sake of sharing data
and for the sake of definition. OOP is a programming convenience, nothing
more. C works fine. Structs work fine. OOP is not a design methodology
although there are methdologies that work best with OOP.
>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.
Yes. Understood. Information hiding is descriptive although one usually
has to describe why it is "hidden" and that may become tedious because
people resist "need to know" explanations. Basic paranoia.
>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
Precisely. Welcome to the original dilemma of CALS that drove SGML to
the surface. We couldn't share implementations but we could share
(or so we thought) standard document types. It turned out that even
in the most disciplined of enterprises, military services, this was
difficult because they are Tri-service and every bit as competitive
as Microsoft, IBM and Oracle (and they have guns! ;-)).
>that couldhave 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.
Yes. The issue of tool-appropriateness. An XML editor can edit any XML but
as soon as one does graphics, one sees the problem with clarity. The politic
of the interface is bounded by the application task.
>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.
A data warehouse solves the problem by creating a central server
for the storage of common data in an agreed upon common format that
is optimal for querying and doing common tasks. A good example
is analysis. Many enterprises contribute data to a statistical
system used to make forecasts about business conditions and needs
for resources. This warehouse would not be useful for actually
doing the business of the business but is for managing the business.
Many can't see the difference or understand that the warehouse
may not be a common repository for all business information, that
in fact, multiple warehouses may be needed. That is one reason
why web services have to be proxied.
> 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.
If REST is simply about using URLs and a primitive method set over which one
builds more complex actions, it depends on where one does the complex actions.
I don't have an alternative, but if I have a proxy (say controller) that
listens for messages, I want it to route to the right warehouse. Then
I want that warehouse to do what it does best.
>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.
A URL with a set of query terms is not much different than an RPC call.
It is just a standard way to package a query. The work is done by the
controller.
>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.
HTTP works like Microsoft works: a single vendor. Ubiquity is about
a singularity.
>Do you want to fight the battle to get something else
>ubiquitously deployed in its stead? I don't.
No nor will I have to. But if the code on the loading dock for
building web services does not support REST du jure, I will use
what it does support and work it out customer by customer. My
singularity is a code base that my team delivers. They want to
talk to that. We expose will expose interfaces to the warehouses
it feeds (one has to be a little crazy to put the central records
management system for police databases online).
>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.
Good so far. But behind that are particular ORBs.
> REST uses hyperlinked documents for state representation rather than
> objects.
It can simply send XML data objects. I won't always need hyperlinks
and in many cases, that will be inconvenient.
>REST relies upon a genericity of methods for large-scale interactions
>rather than type-bound methods.
At the cost of having complex objects behind the generic methods. But
that is ok.
>These things work quite well with HTTP. OO types don't.
OO types may be behind them in the layer that supports the HTTP
request. It still works. It is an issue of how much complexity
is exposed at the perspective boundary.
><snip> 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.
I think OO at the perspective boundary in and of itself is violating
information hiding. The question is not is REST different from OO,
but what is the scale of the object being addressed? An enterprise
sized object does not work with finely-grained transactions or methods.
Scale is the key, but REST is simply a way of interfacing to a very
large object. It can interface to a small one too but only through a
controller.
>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.
Agreed, but if you try to hyperlink to an RFP response, you won't find
one there. If you send a request to engage in an RFP process, we
can expose a form that enables you to engage us.
len
|
