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.
No. If I mention Java, or Jini, do you only thing about distributed Objects?
Its important to understand what the JERI stack allows you to abstract away
from
your software.
In an SOA client/server application, how would you codify, in Java, the action
of sending something from one side to the other? At an architectural level,
you
want to have the least amount of coupling of the transport and invocation layer
to the application right? It's that level of abstraction that I am driving at.
> 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.
Explain how my use of Jini/Java will not allow me to make coarse calls. This
topic keeps comming up in some of the arguments here and I'm afraid that some
ignorance is poised behind these statements and I'd like to eliminate that
issue
because it really does make these arguments have little substance in the
arguments.
> The danger in approaching Web services as "just another distributed
> 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.
I'm still confused about this whole line of argument. Hopefully you can
clarify
why you think that Jini/Java can only provide a conventional "distributed
object
paradigm" of programming. Jini/Java make it possible to have effective and
changable remote object interactions, but that doesn't mean its the only result
of calling a method that results in an interaction with a remote entity.
> 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.
CORBA is not Jini, Jini is not CORBA. The big, big, big differences are:
1. mobile code
2. a programmable/pluggable transport layer
3. a programmable/pluggable invocation layer
4. mobile code
5. did I mention mobile code.
People who only have CORBA and RMI experiences without the JERI stack will
likely mostly just see the CORBA like nature of RMI. Many people using RMI
still seem to not understand how, when or why to use mobile code.
> 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.
This is where the JERI stack and mobile code can make everything fit. Because
I
can change the invocation layer and the transport arbitrarily in the life of
the
service, the clients of the service can always have exactly the optimizations
and mediations they need for access to the service. I write the service
exactly
once, and then adapt and change the deployment over time.
Gregg Wonderly
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/
