Ernie Varitimos wrote:
> The problem with RMI and Jini was at first marketing, Sun blew it. If
> it had been accompanied with a better story from the beginning,
> perhaps applications servers would have been Jini-based.
>
> As a stand-alone technology it suffers because of complexity of setup
> and configuration. Requiring a registry and lookup service that you
Not anymore. As of Jini 2.1 you have an installer to do the work for
you and a setup/testing tool that checks everything is as it should be.
Blitz JavaSpaces (one of my works) also has an installer that sets up
everything in one click, config files, .bat or .sh etc.
I'm not sure what you mean by registry (maybe RMID?) - these days, you
only need a lookup service - that's it.
> must have running to make remoting work is more weight than most are
> willing to deal with. We already have well established IP standards
> that provide these services (DNS, DHCP). An ancillary problem is
> exception handling. It's simply not robust enough.
>
> We need a remoting library that runs over IP networks that requires
> zero configuration, zero setup, like Bonjour. If Bonjour or a Bonjour-
Zero configuration? Are you assuming the IP network is already properly
configured? Are you assuming static or DHCP assigned addresses? Are
you planning to use multicast or broadcast? Over time, we've found Jini
is rarely a problem to configure - it's broken network configuration
which is an issue - more often than not, broken naming service or
IP/hostname mapping.
Jini can do most of your Bonjour scenario out of the box these days.
There's one little tweak I can think of that would be needed but, after
that, you'd be done. And it'd be pretty trivial to make that tweak on
top of what is already there.
> like technology were built into the JVM, RMI would be unnecessary,
> and remoting would be cleaner and easier. Although, this does not
> address exception handling.
>
Nor does it handle network latency, timeouts, concurrency/scaling etc.
These are design issues of course, but they must be tackled in a
different way from the way one designs for a single, non-networked,
in-JVM application.
My two cents,
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/
