|
|
Re: OK, Pile on the new guy
|
Posted: Apr 21, 2004 9:53 PM
|
|
I've tried to provide substantive information here regarding the questions in the Todd's post. We are trying to understand your position Todd, and your questions and comments do strike some nerves it appears, so the things you are asking and saying are important to clear up.
> Like Java itself, Jini bundles up a bunch of older ideas
> from other technologies. There have been many
> lookup/lease/discovery/binding mechansims for all sorts of
> network resources long before Java, much less Jini.
There are a fundamental set of things about distributed computing that everyone does. There is method/messaging, there is usually a proxy to manage the interface between the application and the network. There can be many levels/layers of API that allow lots of different things to be customized (as is the case with Jini 2.0). So, yes, you see lots of commonality and if you stop there, you won't see the other things that are Jini.
When you've decided to use another language or feature of a platform, have you always been forced to use it due to a business need, or have you been able to play and explore? I am curious where the barrier between you and Jini comes from and what issues are truely detracting.
> Incidentally, I'm not a web services fan either. WS
> standardization effort looks quite a lot like the OMG
> efforts on CORBA - same learning curve. Soon they'll be
> adding transactions...
Web Services will soon be a large, ugly hairball, as opposed to its current unattractiveness...
> Sure. Smalltalk, Ruby, and Objective C are message
> passing languages. I can send any message to any object
> at any time.
public interface MessageReceiver extends Remote {
public Object send( Object msg ) throws RemoteException;
}
> http://cocoadevcentral.com/articles/000062.php
>
> Above is a link to a basic tutorial. DST (Distributed
> Smalltalk) worked essentially the same way using the IIOP
> wire protocol. Compare this with the amount of code to do
> roughly the same thing in:
>
> http://www.oreilly.com/catalog/jininut/chapter/ch04.html
>
> Man, what a lot of plumbing I have to master just to move
> a chunk of processing. Why is there so much more code?
Because they are showing you all the details. The ServiceDiscoveryManager provides 2 statement service lookup.
public class MyMessageSender {
Configuration config;
MessageReceiver recv;
ServiceDiscoveryManager sdm;
public MyMessageSender( Configuration conf ) {
this.config = conf;
sdm = new ServiceDiscoveryManager(
null, null, conf );
}
public Object doWork( String dataMsg ) {
ServiceItem item = (MessageReceiver)sdm.lookup(
new ServiceTemplate( null, new Class[] {
MessageReceiver.class }, null ),
null // no filter needed
);
recv = (MessageReceiver)getProxyPreparar().
prepareProxy( item.service );
return recv.send( dataMsg );
}
}
Frameworks such as my startnow project on jini.org, amongst several other similar concepts make it possible to create service implementations with minimal lines of code, as in:
public class MyService extends PersistantJiniService
implements MessageReceiver {
public MyService( Configuration conf ) {
super(conf);
startService( conf, "My Service", "persist.ser" );
}
public MyService( String args[] ) {
super(args);
startService( "My Service", "persist.ser" );
}
public Object send( Object msg ) {
...
}
}
Doesn't seem like that much code to me.
> Because Java, like C++, is a function calling language -
> its inconceivable that an object might not implement a
> function. It enforces this view of the world by requiring
> you to write interfaces, then using code generation for
> stubs, which spits out proxy and implementation classes
> that implement the interface. You end up with one proxy
> class for every class of distributed object.
JDK1.5 no longer requires rmic. The JERI work in Jini 2.0 also uses dynamic Proxy implementations that remove all the hassles associated with rmic and simple downloaded proxies. And, JERI does this in JDK1.4.
> This also adds distribution issues WRT to version
> interfacing BTW. Your client MUST have the appropriate
> interface (and correct version) at compile time - or you
> can jump through hoops and use the very un-natural and
> labor intensive reflection api - but at that point its
> just way too much work for too little payoff.
The interface is a contract that makes it a lot easier for everyone to know what the system does. Developers will be able to replace piece-parts with all symantics of all operations very well documented. In a smalltalk or other dynamic language, you can end up with subtle side effects in places such as the default message handler and elsewhere that make it very difficult for people to just walk in and adjust the system for a slightly different task. There can be side effects that are not a visible part of the system.
> Which brings me back to my earlier assertion -
> distribution is clearly more work for the programmer (in
> the case of Java - MUCH more), more work for the computer,
> and may or may not provide you with a great payoff. So do
> developers not "get it"? Or do they just have more
> pressing business logic to write and not enough
> time/motivation to do boiler plate plumbing? I know where
> I stand on this. Remote interfaces cost more money than
> local ones and I can usually do without them.
What you are supposing is that somehow the only important consideration of distributing a system is that it might make the work between any two parts of the system slower. What you fail to take into account is that threading can reduce latency related to distributed systems. And, the idempotency of remote method calls helps make sure that you can multi-thread without state related issues where multiple threads comming from remote VMs might corrupt state.
When state is important each remote client can have a smart proxy or a remote reference to a unique object that holds some state if needed. You can then use the distibuted leasing model to make sure that any shared knowledge between the client and server is dropped when the client disappears in an abnormal situation.
> The arguments about half baked exception handling to deal
> with network reliability is well taken - but I'd argue
> that the more natrual solution is to have your services
> participate in transactions and make use of JTA.
Transactions are great for maintaining consistancy of global resources. But each VM still needs to manage socket connections, proxy instances etc., related to network failures. So, there is some work where you really need to use Exception handling to help you know when things need to be cleaned up.
> Now here's a chance for you to educate me - If I am to use
> a distributed SOA then I am going to likely require
> distributed transaction management. Looking at the Jini
> docs - it looks like Jini has its own transaction manager
> - does this manager interop with the JTS/DB Transactions I
> find in my local J2EE server?
>
> Its not at all clear to me but looking at the package
> names my guess is NO. The are independent mechanisms. In
> which case they ought not to be mixed. I'd be pleased to
> hear I'm wrong about this though.
A simple adapter service would allow Jini services to participate in JTA based transactions. However, the JTA model within your APP server may not allow you to 'export' a transaction for remote use. So, you would need to put a Jini service within your APP server that would provide the remote RMI semantics for a Jini service.
|
|
Previous Topic
