Here is a contribution from Oliver Sims to the debate on this blog and elsewhere.
I agree. JINI is predicated on tight binding. This is badness for enterprise (and many other) systems. Even in thought experiments assuming infinite bandwidth and computing power, tight binding for anything other than in-process stuff comes adrift when you consider maintenance.
Essentially, unless very well designed (and the Java people have not always shone on that front) tightly-bound distributed objects end up as a distributed miasma - distributed spaghetti code - that is a web of criss-crossing dependencies too complicated ever to debug or evolve.
Also, we found that tight couplings leak! Their tightness leaks into the rest of the network. Whereas loose coupling a la web services form a natural barrier between "my" objects (in the same address space, all designed and built by "me", preferably as one or more components) and "other people's" objects elsewhere in the world (from the next address space to the other side of the world - or the solar system, whatever). In addition, good middleware provides local optimisation for "other" components that just happen to have been deployed in the same address space as that in which "my" components have been deployed.
Remember what happened to CORBA when people thought all objects were Corba objects: nothing ran - OK, it did, but they pulled the plug after two years of running without even initialization completing!
JINI may be a neat idea for closed high-bandwidth networks (that allow plug-ins) and where all computing is Java. It borrows a lot from the ancient idea of downloadable proxies. So do web service implementations (so that, as Lawrence said, developers never have to see HTTP, XML, SOAP, WSDL). And since some Web Service products also provide for local optimisation, I can't immediately see what use JINI is - at least in the context of open (i.e. not closed) distributed systems.
See also comment by Oliver Sims on software factories
No comments:
Post a Comment