Hmm, so this has got my attention - please don't take the below as
aggressive. Just trying to get where you're coming from.
Andrew S. Townley wrote:
> Hi Gregg,
>
> On Thu, 2006-04-06 at 03:34, Gregg Wonderly wrote:
>> If you are doing Java, you should be using just RMI based API interfaces to
>> everything, and making using use of JERIs pluggable stack to give you the
>> SOAP
>> or other WS-* support you need to talk to non-Java clients/servers on the
>> other
>> side.
>
> Does this imply you think of Web services as "just another distributed
> object paradigm"? I think that's a dangerous assumption to make.
>
What's your definition of Web Services? Is it REST or WS or something else?
> I think the good thing about REST is that it makes you think about the
> resource, e.g. the data that you're dealing with. If Fowler's first
> rule of distributed computing is "don't distribute", then the corollary
> to that is to make your remote calls as coarse as possible.
>
Can't say I agree - it's got nothing to do with Fowler's law. It's got
to do with the nature of networks and how to be efficient across them
when you have to use them.
And I don't see what that has to do with REST per se - can you explain
further please? Why do you have to be using REST to think about
resources? And why is thinking about resources/data good?
> The danger in approaching Web services as "just another distributed
Where your definition of Web services is yet to be clearly defined (see
above)
> object paradigm" is that if you approach the problem with a traditional
> programming mindset using RPC interactions (local or remote), then I
> would posit that you're really missing the paradigm of Web services. In
> my mind, there's as big of a jump from traditional distributed computing
> to Web services as there is from procedures to objects.
>
And what do you think the jump is?
And what do you think the paradigm is?
I'm dumb - enlighten me.
> This isn't to say that you can't make your approach work, but I think it
> isn't the best fit. A similar thing is that you can define
> coarse-grained, message-based interactions via CORBA/IIOP using a MEST
> style, but most people don't because that's not how they approach
> problems using those technologies.
>
But surely this simply points to the fact that people color their
architectural thinking with their favourite programming/technological
approach. That's bad design in my book - architecture first, tech second.
An architecture addresses and deals in a set of concerns and
requirements which I then need to express in selected technologies. The
technologies I select are dictated by how well they let me address my
architecture's design and concerns.
If I'm dealing with networks, I consider latency, network partition etc.
> In most cases, if you don't know if the service you want is local or
> remote (at least from an invocation point of view), you're likely to
> make the wrong design decisions. You may choose to deploy a set of
> services so that the actual communication is via in-memory messaging for
> efficiency/scalability considerations, but that should not be part of
> the decisions you make when you design the code that invokes it.
>
Indeed - you probably have to assume that everything is networked -
which kind of sounds like everything is distributed doesn't it? Is that
a good thing?
My point in all of this is that when you build a networked system, there
are a set of things you should be thinking about regardless of your
chosen way of modelling the system (resources, objects or whatever). If
you magically start thinking about these things only because you've
started doing web services your thinking prior to that was faulted.
That's not a plus for web services, that's a minus for poor design and
architecture.
Exercising my curious mind,
Dan.
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
