Looking at Jini in more detail has been on my list for some time (I'm
still trying to find the time to read the Erlang OTP stuff Patrick
pointed me to back in June!). I can't really say one way or another
because my background on Jini is only from what you've posted here, but
mobile code and the invocation semantics you illustrate below is still
to me a different paradigm than what I was trying to explain to Steve
the other day about distributed hypermedia interfaces.
I'm not saying they aren't useful or don't have their place, but I don't
really see that you have any more flexibility in adapting your system
from a client to server point of view with Jini than you do with any
other OO technology. REST, and the potential advantages I see in that
approach as they apply to wide-scale enterprise distributed computing
are orthogonal to expressing a service interface as an API.
Thanks for the examples. Makes me wish I had more time at the moment to
play with it. :)
Cheers,
ast
On Tue, 2006-12-12 at 03:57, Gregg Wonderly wrote:
> Andrew S. Townley wrote:
> > I guess to me I see a difference between early and late binding. To be
> > honest, I'm probably more of a Uniform Pipes & Filters (UPF) guy than
> > anything, but when you have a generalized invocation mechanism that
> > allows anyone interested and capable of responding to the message (e.g.
> > NEXTESTEP/MacOS responder chain--an example of the GoF Chain of
> > Responsibility), you aren't directly tied to selecting or interacting
> > with a particular endpoint. To me I see this as one of the main ways
> > towards achieving loose coupling between service requesters and
> > providers.
> >
> > I know you can do this sort of thing with dynamic proxies in Java to
> > some degree, but I haven't looked at them in great detail.
>
> I can "lookup" a service to perform the late binding to implementation. That
> implementation may be the implementing object, or it might be a remote
> implementation. Only mobile code can provide that choice to the service
> deployer. That seems to me to be as loose as it gets. That contract
> decribed
> by the implementation that I download will be exactly what I need. In Jini,
> I
> can perform the lookup using type based matching so that I can be specific
> about
> any assumptions that my client has with regard to the implementation.
>
> > I agree with you that it's about messages (i.e. data, not method calls),
> > their structure and the business level exchange protocols, but I'd
> > rather not have to worry much about how to get those messages from point
> > A to point B.
>
> When I write a Jini client, I code stuff like
>
> Worker wrkr = lus.lookup( Worker.class );
> wrkr.doSomething( some, args, of, some, sort );
>
> There is a great deal of flexibility and customization possible with the use
> of
> the existing lookup service in Jini, and because of mobile code, you can
> define
> your own to work however you need. For example, I could return a Java remote
> proxy via an HTTP request.
>
> There isn't any worrying about how to get something from point A to point B.
> I
> just need to make the appropriate parameterization of the invocation, exactly
> as
> I would if I instead coded:
>
> URL u = new URL("http://my.host.com/worker?some=1&args=2";);
> Object obj = netHandler.read( u );
>
> > I don't know if this helped any, but from the way I view distributed
> > systems, there is a pretty real difference.
>
> I'm still unsure of where the difference is, other than a software
> architecture
> issue that has already been recognized and is on many architects toolbelts.
>
> Gregg Wonderly
>
>
>
> Yahoo! Groups Links
>
>
>
--
Andrew S. Townley <[EMAIL PROTECTED]>
http://atownley.org
